Secondary device as key for authorizing access to resources

ABSTRACT

A secondary device may be used to provide access to resources to a primary device. Upon receiving an authorization indication at a device, a registration key based on the authorization indication, a user identifier, and a property of the device may be created. Upon determining whether access to at least one resource is permitted according to the registration key the device may be permitted to access the at least one resource.

RELATED APPLICATION

This application is a Continuation of U.S. patent application Ser. No.14/083,718, entitled “Secondary Device as Key for Authorizing Access toResources,” filed on Nov. 19, 2013, which is a Continuation-in-Part ofU.S. patent application Ser. No. 13/841,853, entitled “Secondary Deviceas Key for Authorizing Access to Resources,” filed on Mar. 15, 2013,both of which are hereby incorporated by reference in their entirety.

BACKGROUND

Managing access to enterprise resources by network-connected devices iscritical to ensure that only authenticated and authorized users anddevices gain access to sensitive information or services. To date, thishas typically been accomplished by utilizing network firewalls, reverseproxy servers with authentication, and encrypted VPN tunnels. Today,however, enterprise resources are being moved out of enterprise-manageddata centers and into the “Cloud.” These cloud-based networkenvironments may not provide the configurability and customizationnecessary to sufficiently protect enterprise resources. For instance,protecting enterprise-managed data centers at a device level can beproblematic. Cloud-based data services often do not provide thenecessary features to allow enterprises to manage access to the servicesat a device level.

SUMMARY OF THE INVENTION

The disclosed embodiments relate to a system and associated devices andmethods for managing access to resources in a networked environment. Aclient side application executed on a client device may transmit arequest to an authorization service for access to a resource. Theauthorization service may then authenticate user credentials and/or adevice identifier received from the client side application.Authenticating the user credentials and/or the device identifier mayinclude determining that the user credentials and/or the deviceidentifier is/are associated with the resource.

The client side application may then receive from the authorizationservice an indication that the client device must comply with adistribution rule associated with the resource, where the distributionrule requires a specified secondary client device to be in communicationwith the client device as a prerequisite to accessing the resource. Insome cases, the fact that the specified secondary client device is incommunication with the client device is all that is required toauthorize the client side application (with the user and/or clientdevice having been previously authenticated) to access the resource,which may be accessed by the client device from an enterprise server orfrom the local memory of the client device.

In some embodiments the client side application determines that theclient device complies with the distribution rule and then communicateswith the secondary client device to gain access to the secure copy ofthe resource. In some cases this involves the client side applicationreceiving from the secondary client device an authorization credentialto be used for receiving authorization to access the resource. In someembodiments, the client side application may transmit the authorizationcredential to a distribution service that will provide authorization toaccess the resource upon authenticating the authorization credential.

In some embodiments, the resource is stored in a secure format in amemory of the client device and the authorization credential receivedfrom the secondary client device is used to access the resource from thememory. The secondary client device may receive the authorizationcredential from the authorization service after the authorizationservice authenticates user credentials and/or a device identifierreceived from the secondary client device. This authentication mayinclude determining that the user credentials and/or the deviceidentifier received from the secondary client device is/are associatedwith the resource. In some embodiments, the authorization servicefurther determines whether the secondary client device complies withadditional distribution rules associated with the resources and/or theauthorization credential. The authorization credential may be at leastone of a PIN, a key, a password, a certificate, and a token.

In some embodiments the client device may transmit the secure resourceto the secondary device and receive an accessible copy of the resourcefrom the secondary client device. Again, the secondary client device mayreceive the authorization credential required for accessing secureresource from the authorization service. Alternatively, theauthorization credential may be provisioned in the secondary clientdevice.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood withreference to the following diagrams. The drawings are not necessarily toscale, emphasis instead being placed upon clearly illustrating certainfeatures of the disclosure. Moreover, in the drawings, like referencenumerals designate corresponding parts throughout the several views.

FIG. 1 is a block diagram of a networked environment according tocertain embodiments.

FIG. 2 is a flowchart illustrating an example of a method performed by aclient side application attempting to access a resource stored on anenterprise server.

FIG. 3 is a flowchart illustrating another example of a method performedby a client side application attempting to access a resource stored onan enterprise server.

FIG. 4 is a flowchart illustrating an example of a method performed byan authorization service for authorizing or denying access to resources.

FIG. 5 shows schematic block diagrams illustrating certain components ofan enterprise server and a client device employed in the networkedenvironment of FIG. 1.

DETAILED DESCRIPTION

Disclosed are various embodiments for a system and associated devicesand methods for managing access to resources in a networked environment.In some embodiments, the system comprises an enterprise server, aprimary client device and at least one secondary client deviceconfigured as described herein. The enterprise server may store orotherwise control access to resources, such as data, databases,application programs and application files, text files, word processorfiles, spreadsheet files, presentation files, graphic files, audiofiles, photographic files, video files and/or the like. The enterpriseserver may execute an authorization service for determining whether toauthorize access to resources. The enterprise server may also execute adistribution service for providing resources to the client device(s) orproviding the client device(s) with access to resources.

In some embodiments, a user operates a primary client device andexecutes a client side application that attempts to access at least oneresource hosted on the enterprise server. The authorization service mayfirst attempt to authenticate user credentials associated with the userof the primary client device and/or a device identifier that uniquelyidentifies the primary client device. User credentials may include oneor more of a user name and password, biometric data, and/or other dataused to identify the user. The device identifier may be a uniquehardware identifier such as a GUID (Globally Unique Identifier), UUID(Universally Unique Identifier), UDID (Unique Device Identifier), serialnumber, IMEI (Internationally Mobile Equipment Identity), Wi-Fi MAC(Media Access Control) address, Bluetooth MAC address, a CPU ID, and/orthe like, or any combination of two or more such hardware identifiers.Additionally, the device identifier may be represented by a uniquesoftware identifier such a token or certificate, based at least in parton the aforementioned unique hardware identifiers.

As an additional security measure, the authorization service may requirea secondary client device, which may be a specific client device or oneof a group of specific client devices (collectively referred to hereinas a “key device”) to be in communication with the primary client deviceas a prerequisite to accessing the requested resource(s). If the primaryclient device is in communication with the key device, the primaryclient device may then be authorized to access the resources.Alternatively, the primary client device may be required to interactwith the key device to gain access to the requested resource(s), asdescribed herein.

In some embodiments where the primary client device is required tointeract with the key device to gain access to the requestedresource(s), the primary client device may obtain from the key device anauthorization credential, such as a decryption key, PIN, password,certificate and/or token, etc., required for access to the requestedresource(s). For example, the primary client device may provide theauthorization credential to the authorization service or thedistribution service to gain access to the requested resource(s).

In some embodiments, the authorization service may instruct thedistribution service to provide the requested resource(s) to the primaryclient device in an encrypted or otherwise secure format. The primaryclient device may obtain a decryption key or another authorizationcredential from the key device, which may be used to decrypt theresource(s) or otherwise access the resource(s). As another example, theprimary client device may transfer the encrypted or otherwise secureresource(s) to the key device, which may decrypt or otherwise render theresource(s) accessible (unsecure) and return the unsecure resource(s) tothe primary client device. In such cases, the key device may already beprovisioned with a copy of the decryption key or other applicableauthorization credential, or may obtain the decryption key or otherauthorization credential from the authorization service.

FIG. 1 illustrates an example of networked environment 100 according tovarious embodiments. The networked environment 100 includes anenterprise server 103, a primary client device 106, at least onesecondary client device (which functions as the key device 108) and anetwork 109. The network 109 may be or include, for example, any type ofwireless network such as a wireless local area network (WLAN), awireless wide area network (WWAN) or any other type of wireless networknow known or later developed. Additionally, the network 109 may be orinclude the Internet, intranets, extranets, microwave networks,satellite communications, cellular systems, PCS, infraredcommunications, global area networks, or other suitable networks, etc.,or any combination of two or more such networks. The network 109facilitates transmission of communications and resources between one ormore client devices 106, 108 and the enterprise server 103.

By way of example, a client device 106, 108 may be a desktop computer, alaptop computer, a personal digital assistant, a cellular telephone, aset-top box, a music player, a web pad, a tablet computer system, a gameconsole, and/or another device with like capability. A client device106, 108 may include a wired network connectivity component (not shownin FIG. 1), for example, an Ethernet network adapter, a modem, and/orthe like. A client device 106, 108 may further include a wirelessnetwork connectivity interface (not shown in FIG. 1), for example, a PCI(Peripheral Component Interconnect) card, USB (Universal Serial Bus)interface, PCMCIA (Personal Computer Memory Card InternationalAssociation) card, SDIO (Secure Digital Input-Output) card, NewCard,Cardbus, a modem, a wireless radio transceiver, and/or the like. Aclient device 106, 108 may thus be operable to communicate via wiredconnection with the enterprise server 103 with the aid of the wirednetwork connectivity component. A client device 106, 108 may be furtheroperable to communicate wirelessly with the enterprise server 103 withthe aid of the wireless network connectivity component.

Additionally, a client device 106, 108 may further comprise a memory forstoring data and application programs, a processor for executingapplication programs and other executable instructions stored in thememory, and a local interface such as a bus, as will be described withrespect to FIG. 5. A client device 106, 108 may also include a display116, 118 for rendering user interfaces 129, 131. The memory of theclient device 106, 108 may contain a data store 113, 115. In certainembodiments, the data store 113, 115 may store certain data andapplication programs. In the case of the primary client device 106 andfor purposes of the present discussion, the data store 113 may store adevice profile 119, user credentials 127, a device identifier 128, anapplication program for accessing and managing access to resources(referred to herein as a “client side application” 123), as well asother application programs and data. In the case of the key device 108and for purposes of the present discussion, the data store 115 may storea device identifier 156, an application program for enabling orfacilitating access to resources (referred to herein as a “keyapplication” 163), as well as other application programs and data.

The device profile 119 may indicate various hardware, software, andsecurity attributes or other configurations of the primary client device106. For instance, the device profile 119 may indicate hardwarespecifications of the primary client device 106, version andconfiguration information of various software programs and hardwarecomponents installed, enabled and/or executing on the primary clientdevice 106, transport protocols enabled on the primary client device106, version and usage information of various other resources stored onthe primary client device 106, and/or any other attributes associatedwith the state of the primary client device 106. The informationincluded in the device profile 119 and other data stored on oraccessible to the primary client device may be used to verify that theprimary client device 106 complies with one or more distribution rule(s)145 that may be associated with certain resources 139.

Distribution rules 145 may specify certain hardware, software and otherdevice parameters or configurations with which the primary client device106 or any other client device must comply before it will be authorizedto access any resources 139 associated with such distribution rules 145.In some embodiments, a distribution rule 145 associated with a resource139 may specify that the primary client device 106 must be incommunication with a key device 108 as a prerequisite to the client sideapplication 123 or any other application program executed by the primaryclient device 106 gaining access to that resource 139. For example, theresource 139 may not be provided or made accessible to the client sideapplication 123 unless and until compliance with the distribution rule145 is confirmed.

In some embodiments, the client side application 123 will be authorizedto access the resource 139 as long as the primary client device 106 isin communication with the key device 108. The authorization service 136may facilitate access to the resource 139 by the client side application123, for example via the distribution service 137. Alternatively, theauthorization service 136 or may authorize or enable the client sideapplication 123 to access the resource 139 from the local memory of theprimary client device.

As used herein the phrase “in communication” is meant in its broadestsense, i.e., that at least one signal transmitted by one device isreceived by another device. An active two-way communication session isnot required. Thus, for instance, one client device (e.g., the keydevice 108) may broadcast a beacon or some other self-identifying signalthat may be received by another device (e.g., the primary client device106) and, in the context of this disclosure, the devices are consideredto be in communication with each other. Therefore, the client sideapplication 123 may simply search a listing of potential Bluetooth orproximity based communication pairings, etc. to confirm that thespecified key device 108 is broadcasting a signal and is within thepresence of the primary client device 106. Therefore, based on thedetected presence of the key device 108, the client side application 123may confirm compliance with the distribution rule 145 and thereby gainaccess to the resource 139.

In some embodiments, the client side application 123 will be required tointeract with the secondary client device 106 to gain access to theresource 139. For example, the client side application 123 may receivean authorization credential 166 from a key application 163 executed onthe key device 108 and may then provide it to the distribution service137 or authorization service 136. As another example, the resource 139may be provided to the client side application 123 in a secure format(e.g., encrypted, password protected, etc.) and the client sideapplication 123 will be required to cooperate with the key application163 executed by the key device 108 to gain access to the secure resource139. The key application 163 may be configured for retrieving applicableauthorization credentials (e.g., decryption keys, PINs, passwords,certificates, and/or tokens, etc.) from the data store 115 of the keydevice 108 or may request such items from the authorization service 136as needed.

In some embodiments, the client side application 123 may be executed totransmit to the enterprise server 103 a request 153 for access to atleast one resource 139. The client side application 123 may also includefunctionality for rendering a user interface 129 on the display 116 andfor displaying resources 139 therein. In some embodiments, the clientside application 123 may render an interface that presents an array ofresources 139 in a single view, such as in a category-based tree oroutline format. As will be appreciated, the client side application 123may also include functionality for receiving and responding to userinput commands generated by various input/output devices.

In some embodiments, the client side application 123 may be a securecontainer program that may be authorized to receive and render selectedresources 139. The secure container program may also execute otherapplication programs within its secure environment, where suchapplication programs are stored locally on the client device 106 and/oron the enterprise server 103 or another network device. By way ofexample, such other applications may include web browsing applications,email applications, instant messaging applications, and/or otherapplications capable of receiving and/or rendering resources 139 on thedisplay 116.

In some embodiments, where the client side application 123 is not asecure container program, the client side application 123 may beconfigured with instructions for communicating with and executingcommands received from the authorization service 136 for performing theauthorization methods described herein. Such instructions may beincluded in or called by the program code of the client side application123 or may be provided by a wrapper applied to the client sideapplication 123.

In some embodiments, key device 108 may continuously and/or periodicallybroadcast an authorization indication (such as a location identifierand/or key device identifier 156) via network 109. In some embodiments,key device 108 may provide such an authorization indication to primaryclient device 106 upon a manually triggered request from a user ofprimary client device 106 and/or upon detection of primary client device106 within a configurable proximity to key device 108 and/or ageographic location served by key device 108. Client device 106 may thencreate a registration key according to various criteria, such as theauthorization indication, user credentials 127, and/or devicecharacteristic and properties, such as primary client device identifier128. This registration key may then be provided to enterprise server 103and/or key device 108 in order to register the primary client device 106for access to resource(s) 139. Such registration may comprise entry ofthe registration key in a registration database or other tracking tableand may require evaluation of the primary client device 106 with respectto compliance rules and/or distribution rules 145. Once the registrationkey has been entered and approved, authorization credentials 166 may beprovided to primary client device 106 to enable access to resource(s)139.

In some embodiments, the compliance of primary client device 106 withthe application compliance and/or distribution rules 133 may beevaluated on a periodic basis and/or each time primary client device 106requests access to resource(s) 139. In some embodiments, theauthorization credentials may comprise compliance restrictions such as arequirement for primary client device 106 to remain within aconfigurable proximity of key device 108 in order to continue and/orrequest further access to resource(s) 139. In some embodiments, theauthorization credentials 166 may comprise an expiration time; such anexpiration time may comprise a fixed time and/or date that theauthorization credentials 166 expire and/or a duration of time from theprovision of the authorization credentials 166.

The enterprise server 103 may comprise, for example, a server computeror any other system providing and authorizing access to resources 139.Alternatively, a plurality of enterprise servers 103 may be employedthat are arranged, for example, in one or more server banks or computerbanks or other arrangements. For example, a plurality of enterpriseservers 103 together may comprise a cloud computing resource, a gridcomputing resource, and/or any other distributed computing arrangement.Such enterprise servers 103 may be located in a single installation ormay be distributed among many different geographic locations. Forpurposes of convenience, the enterprise server 103 is referred to hereinin the singular. Even though the enterprise server 103 is referred to inthe singular, it is understood that a plurality of enterprise servers103 may be employed in the arrangements as described herein.

The enterprise server 103 may execute various application programs,services and other processes. For example the enterprise server 103 mayexecute the authorization service 136 and a distribution service 137that distributes resources 139 to client devices 106 or otherwiseprovides client devices 106 with access to resources 139. It should beunderstood that in some embodiments, the authorization service 136 maybe executed on one or more other network devices, such as a proxy serverand/or a compliance server. It should also be understood that, in someembodiments, the functions of and processes performed by theauthorization service 136 described herein may be distributed among aplurality of different services, including an authentication service forauthenticating user and device credentials and/or a compliance servicefor determining whether primary client device 106 and other clientdevices (e.g., the key device 108) complies with resource distributionrules and other requirements.

Also, certain data may be stored in a data store 133 that is containedin or otherwise accessible to the enterprise server 103. The illustrateddata store 133 may be representative of a plurality of data stores, ascan be appreciated. The data store 133 may utilize strong encryptionstandards to protect against unauthorized access. For example, the datastore 133 may utilize the Advanced Encryption Standard (AES-256) orStandard Hash Algorithm (SHA-1) or any similar strong encryptionstandard commonly utilized for server-side data storage.

In some embodiments, the data stored in the data store 133 includesresources 139, a listing of approved device identifiers 146, a listingof approved user credentials 147, a listing of key device identifiers149 and distribution rules 145. The approved user credentials 147represents user credentials that have been previously approved foraccessing certain resources 139. Similarly, the listing of approveddevice identifiers 146 represents a listing of device identifiers thathave been previously approved for accessing certain resources 139.Accordingly, user credentials 127 and device identifiers 128 receivedfrom the primary client device 106 (i.e., in connection with requests153 for access to resources 139) are authenticated by comparing them tothe listing of approved user credentials 147 and the listing of approveddevice identifiers 146, respectively. In some embodiments, the datastore 133 may store a listing of approved pairings of user credentialand identifiers and the authentication process may involve determiningwhether the user credentials 127 and the device identifiers 128 receivedfrom primary client device 106 match any of the approved pairings. Aswill be appreciated, the key device 108 and/or its user may beauthenticated in the same way.

The listing of key device identifiers 149 represents a listing of keydevices that may be required to be in communication with the primaryclient device 106 in order to “unlock” access to certain resources 139.In the example where a primary client device 106 is a laptop computer ora tablet computer, a key device 108 may be, for instance, the user'smobile phone. Any secondary client device capable of executing the keyapplication 163 for obtaining and providing authorization credentials166 and/or accessing secure resources may function as the key device108. In some embodiments, a service provider or network administratorresponsible for maintaining the security of the resources 139 on theenterprise server 103 may specify which secondary client device(s) mayfunction as the key device 108 for a particular user and/or primaryclient device 106. In some embodiments, more than one key device 108 maybe specified and/or required for compliance with a distribution rule145.

Accordingly, the authorization service 136 may receive from the primaryclient device 106 a request 153 to access certain resources 139. In someembodiments, the request 153 may include or be sent along with usercredentials 127, a device identifier 128 and/or an indication of therequested resource(s) 139. In some embodiments, the authorizationservice 136 may request some or all of such information from the primaryclient device 106 in response to receiving the access request 153. Theauthorization service 136 authenticates the user credentials 127 and/orthe device identifier 128, as described.

As discussed, the authorization service 136 may also require the primaryclient device 106 to comply with certain distribution rules 145 beforeit authorizes the primary client device 106 to access the requestedresource(s) 139. The information required for the compliance check maybe included, for example, in the device profile 119 or otherwise storedin the data store 113 of the primary client device 106. In some cases,the information required for this compliance check may be provided bythe primary client device 106 to the authorization service 136 as partof or along with the access request 153. In some cases, theauthorization service 136 may request such information from the primaryclient device 106 when requesting user credentials 127 and/or the deviceidentifier 128 or in response to authenticating the user credentials 127and/or the device identifier 128.

In some embodiments, one or more distribution rules 145 or associatedkey device identifiers 149 may be provided to the primary client device106 so that an application program (e.g., the client side application123) or other process executed by the primary client device 106 mayperform the compliance check. In these embodiments, the requestedresource(s) 139 may not be provided to or otherwise made accessible tothe primary client device 106 until the authorization service 136receives a notice from the primary client device 106 confirmingcompliance. In other cases, the requested resource(s) 139 may beprovided to or accessed by the primary client device 106 in a secureformat before the compliance check is performed (e.g., the applicabledistribution rule(s) 145 or key device identifier(s) 149 may be providedcontemporaneously with the secure resource(s) 139), but the client sideapplication 123 or other application executed by the primary clientdevice 106 may not have the authorization credential 166 required toaccess or use the resource(s) 139.

A distribution rule 145 associated with at least one requested resource139 may specify that a key device 108 (which may be identified by a keydevice identifier 149) must be in communication with the primary clientdevice as a prerequisite to accessing the requested resource(s) 139. Insome embodiments, the client side application 123 or another processexecuted by the primary client device 106 may be configured forreceiving the distribution rule 145 or key device identifier 149 anddetermining whether the specified key device 108 is in communicationwith the primary client device 106. Communication between the key device108 and the primary client device 106 may be via any suitable wired orwireless network 109 or any direct wired or wireless communication link107 between the devices. For example, a direct wireless connection 107may be achieved WiFi, Bluetooth, infrared signal exchanges, Near FieldCommunication, or any other suitable direct wireless communication link.

In some embodiments, the authorization service 136 may instruct thedistribution service 137 to provide the resource(s) 139 in a secureformat or provide access to the secure resource(s) 139 to the clientside application 123 contemporaneously with the distribution rule 145 orkey device identifier 149. In such cases, the client side application123 may be configured to interact with the key application 163 executedby the key device 108 to gain access to the secure resource 139, asdescribed. In some embodiments, the client side application 123 may beconfigured to receive an authorization credential 166 from the keyapplication 163 and to provide that authorization credential 166 to thedistribution service 137 or the authorization service 136 (which maypass the authorization credential to the distribution service 137 onbehalf of the client side application 123) in order to gain access tothe requested resource(s) 139.

FIG. 2 is a flowchart illustrating an example of a method performed by aclient side application 123 attempting to access a resource 139. Themethod begins at start step 202, where the client side application 123is executed and determines (e.g., in response to a user input command orother run-time requirement) that it requires access to one or moreresources 139, which may be stored on the enterprise server 103 orlocally on the primary client device 106. At step 204, the client sideapplication 123 transmits a request 153 to the enterprise server 103 (ordirectly to the authorization service 139, for example, in cases whereits port is known to the client side application 123 or other processexecuted by the primary client device 106) for access to the requiredresource(s) 139. The request may include user credentials 127, a deviceidentifier 128 and/or an indication of the resource(s) 139 to whichaccess is requested.

Provided that the user and/or the client device 106 have beenauthenticated by the authorization service 136, the method moves to step206, where the client side application 123 receives a distribution rule145 (or the key device identifier 149 associated therewith), requiringconfirmation that a key device 108 is in communication with the primaryclient device 106.

Next, in step 208, the client side application 123 determines whetherthe specified key device 108 is in communication with the primary clientdevice 106. This of course may be done by checking all activecommunication ports, communication links, and potential communicationpairings, etc. to determine the identity (e.g., by way of deviceidentifiers) of any device in communication with the primary clientdevice 106. In some embodiments, the client side application 123 orother process executed by the primary client device 106 determines thatthe primary client device 106 is in communication with the key device108 by matching the key device identifier 149 with the device identifier156 of the key device 108. If it is determined in step 208 that theprimary client device 106 is not in compliance with the distributionrule 145, the method moves to step 210 where a notice of noncomplianceis transmitted to the authorization service 136 (and may be displayed onthe display 116 for the user). From step 210, the method ends at step220.

However, if it is determined in step 208 that the primary client device106 is in compliance with the distribution rule 145, the method proceedsto step 211, where a determination is made as to whether furtherauthorization is required for the client side application 123 to accessthe resource(s) 139. For example, compliance with the distribution rule145 may require only that the primary client device 106 is incommunication with the key device 108 and, if that is confirmed, theauthorization service 136 may provide authorization for the client sideapplication 123 to access the resource(s) 139. In other cases, theclient side application 123 may need a further authorization credential166 to access resource(s) 139 via the distribution service 137 or toaccess secure resource(s) 139 stored locally on the primary clientdevice 106.

Therefore, if it is determined in step 211, that further authorizationis not required, the method moves to step 216 where the client sideapplication 123 receives authorization to access to the requestedresource(s) 139. However, if it is determined in step 211, that furtherauthorization is required, the method moves to step 212, where anauthorization credential 166 is received from the key device 108 (e.g.,by the key application 163). As described, the authorization credential166 may be stored in the data store 115 of the key device 108, or thekey application 163 may be configured to request it from theauthorization service 136. Then in step 214, the client side application123 transmits the authorization credential 166 to the distributionservice 137 or the authorization service 136 and in step 216, if theauthorization credential is authenticated, receives authorization toaccess to the requested resource(s) 139. From step 216, the method endsat step 220.

In some embodiments, the requested resource(s) 139 may have previouslybeen stored in the data store 113 of the primary client device 106, butthe client side application 123 may not have been able to access theresource(s) until receiving authorization from the authorization service136 or until receiving the authentication credential 166 from the keydevice 108, by way of above described or similar method.

In some embodiments, the state of the primary client device 106 may bemodified after the client side application 123 is authorized to accesscertain resources 139. For example, the primary client device 106 maylose communication with the key device 108 in contravention of theapplicable distribution rule 145. As another example, an unauthenticateduser may log-on to the primary client device 106. Accordingly, in someembodiments, the authorization service 136 and the client sideapplication 123 may periodically communicate in order to reconfirmauthentication of the user and/or primary client device 106 and/orcompliance with the applicable distribution rule 145. These subsequentauthentications and/or compliance checks may be performed as describedabove (e.g., by the client side application 123 and/or theauthentication service 136) and, in some embodiments, may be run asbackground processes so as to not require further input from the user.In some embodiments, the authorization granted to the client sideapplication 123 for accessing the requested resource(s) 139 may berevoked and the resource(s) 139 may be deleted from the primary clientdevice 106 and the key device, if applicable, whenever the primaryclient device 106 is determined to be noncompliant with the applicabledistribution rule 145.

FIG. 3 is a flowchart illustrating another example of a method performedby a client side application 123 attempting to access a resource 139stored on an enterprise server 103. The method begins at start step 302,where the client side application 123 is executed and determines (e.g.,in response to a user input command or other run-time requirement) thatit requires access to one or more resources 139 stored on the enterpriseserver 103. At step 304, the client side application 123 transmits arequest 153 to the enterprise server 103 (or directly to theauthorization service 139, for example, in cases where its port is knownto the client side application 123 or other process executed by theprimary client device 106) for access to the required resource(s) 139.The request may include user credentials 127, a device identifier 128and/or an indication of the resource(s) 139 to which access isrequested.

Provided that the user and/or the primary client device 106 have beenauthenticated by the authorization service 136, the method moves to step306, where the client side application 123 receives a distribution rule145 (or the key device identifier 149 associated therewith), requiringconfirmation that a key device 108 is in communication with the primaryclient device 106. Then, in step 308, the client side application 123receives the requested resource(s) 139 in a secure format.

Next, in step 310, the client side application 123 determines whetherthe specified key device 108 is in communication with the primary clientdevice 106. If it is determined in step 310 that the primary clientdevice 106 is not in compliance with the distribution rule 145, themethod moves to step 312 where a notice of noncompliance is transmittedto the authorization service 136 (and may be displayed on the display116 for the user). From step 312, the method ends at step 320. However,if it is determined in step 310 that the primary client device 106 is incompliance with the distribution rule 145, the method proceeds to step313, where a determination is made as to whether the client sideapplication 123 has access to the authorization credential 166 requiredfor accessing the secure resource 139. For example, the authorizationcredential 166 may be stored locally on the primary client device. Ifso, the method moves to step 318, where the client side application 123uses the required authorization credential 166 to access the resource139. If it is determined at step 313 that the client side application123 does not have access to the authorization credential 166, the methodproceeds to step 314, where secure resource(s) 139, or a request for theauthorization credential 166, is transmitted to the key device 108.

As discussed, the key application 163 executed on the key device 108 mayretrieve the applicable authorization credential 166 from the local datastore 115 or may obtain it (or them) from the authorization service 136.In the case where the secure resource(s) 139 are provided to the keydevice 108, the key application 163 will use the applicableauthorization credential 166 to render the resource(s) 139 accessible(unsecure). Therefore, in step 316, the client side application 123receives either the accessible resource(s) 139, or the applicableauthorization credential 166, from the key application 163. Then at step318 that client side application 123 accesses the resource(s) 139 and,from there, the method ends at step 320.

As in the prior example method, in some embodiments, the authorizationservice 136 and the client side application 123 may periodicallycommunicate in order to reconfirm authentication of the user and/orprimary client device 106 and/or compliance with the applicabledistribution rule 145. These subsequent authentications and/orcompliance checks may be performed as described above (e.g., by theclient side application 123 and/or the authentication service 136) and,in some embodiments, may be run as background processes so as to notrequire further input from the user. In some embodiments, theauthorization granted to the client side application 123 for accessingthe requested resource(s) 139 may be revoked and the resource(s) 139 maybe deleted from the primary client device 106 whenever the primaryclient device 106 is determined to be noncompliant with the applicabledistribution rule 145. In addition, in some embodiments, any and allcopies of resource(s) 139 provided to the key device 108 may be removedfrom the key device 108 (e.g., by a function of the key application 163)after the key application 163 decrypts or renders them accessible andprovides them back to the primary client device 106.

FIG. 4 is a flowchart illustrating an example of a method performed byan authorization service 136 for authorizing or denying access toresource(s) 139 stored on an enterprise server 103. From start step 402the method moves to step 404, where the authorization service 136receives a request 153 from a client side application 136 to accesscertain resource(s) 139 hosted by the enterprise server 103. Asdescribed, user credentials 127, a device identifier 128 and/or anindication of the requested resource(s) 139 may be included in or sentalong with the access request 153. Alternatively, the authorizationservice 136 may request some or all of that information in response toreceiving the access request 153.

Next, in step 406, the authorization service 136 determines whether theuser credentials 127 and/or the device identifier 128 is/areauthenticated. As described, this authentication step may involve notonly determining that the user credentials 127 and/or the deviceidentifier 128 is/are valid, but also determining if the usercredentials 127 and/or the device identifier 128 is/are associated withthe requested resource(s) 139. If not, the method moves to step 408where a notification of authentication failure is transmitted to theclient side application 123 and then the method ends at step 320.However, if the user credentials 127 and/or the device identifier 128is/are authenticated in step 408, the method proceeds to step 410, whereat least one distribution rule 145 associated with the requestedresource(s) 139 is identified and such distribution rule(s) 145require(s) at least one key device 108 be in communication with theprimary client device 106 as a prerequisite to accessing the requestedresource(s) 139.

Next in step 412, the distribution rule(s) 145 or key deviceidentifier(s) 149 are transmitted to the client side application 123 orother process executed on the client device 106 so that the compliancecheck can be performed locally on the client device 106. Thedistribution rule 145 may further specify whether (i) no furtherauthorization is required for the client side application 123 to accessthe requested resource(s) 139, (ii) requested resource(s) 139 are toremain on the enterprise server 103 until the client side application123 provides a valid authorization credential 166, or (iii) whether therequested resource(s) 139 are to be provided to the client sideapplication 123 in a secure format. If no further authorization isrequired, the method ends at step 424 and the client device 106 will beauthorized to access the resource(s) 139.

If the requested resource(s) 139 are to remain on the enterprise server103 until the client side application 123 provides a valid authorizationcredential 166, the method moves to step 414, where the authorizationservice 136 receives an authorization credential 166 from the clientside application 123. Then at step 416, the authorization service 136provides or facilitates the provision of authorization to access therequested resource(s) 139, for example by authenticating theauthorization credential 166 or by transferring the authorizationcredential 166 to the distribution service 137 for authentication. Fromstep 416 the method ends at step 424. As previously mentioned, theclient side application 123 in some embodiments will provide anauthorization credential 166 directly to the distribution service 137,meaning that steps 414 and 416 will not be performed.

Returning to step 412, if the distribution rule 145 indicates that therequested resource(s) 139 are to be provided to the client sideapplication 123 in a secure format, the method moves to at step 418,where that action is performed. Then at step 420, the authorizationservice 136 receives from the key device 108 a request for anauthorization credential 166 required for rendering accessible thesecure resource(s) 139. At step 422 the requested authorizationcredential 166 is provided to the key device 108, preferably in responseto authenticating user credentials and/or a device identifier 156associated with the key device 108. For example, the user may beprompted to input user credentials 127 to the key device 108 (e.g., viaa user interface 131 of the key application 163), which may betransmitted to the authorization service 136, possibly along with thedevice identifier 156 of the key device 108. In some embodiments, theauthorization service 136 will require the key device 108 to comply withadditional distribution rules 145 associated with the resource(s) 139and/or the key device 108. Following step 422, the method ends at step424.

FIG. 5 shows schematic block diagrams illustrating certain components ofan enterprise server 103 and each of the client devices 106, 108employed in the networked environment of FIG. 1. The enterprise server103 includes at least one processor circuit, for example, having aprocessor 503 and a memory 506, both of which are coupled to a localinterface 509. To this end, the enterprise server 103 may comprise, forexample, at least one server computer or like device. Similarly, theeach of client devices 106, 108 includes at least one processor circuit,for example, having a processor 553 and a memory 556, both of which arecoupled to a local interface 559. Additionally, each of the clientdevices 106, 108 may be in data communication with a display 116, 118for rendering user interfaces 129, 131 (FIG. 1) and one or more otherI/O devices 563 for inputting and outputting data. To this end, each ofthe client devices 106, 108 may comprise, for example, at least oneclient computer or like device.

The following is a general discussion of the components of theenterprise server 103 and each of the client devices 106, 108. The localinterface 509 and 559 may comprise, for example, a data bus with anaccompanying address/control bus or other bus structure as can beappreciated. Stored in the memory 506 and 556 are both data and severalcomponents that are executable by the processors 503 and 553. Inparticular, with regard to the enterprise server 103, stored in thememory 506 and executable by the processor 503 are an authorizationservice 139 and potentially other applications. Additionally, withregard to each of the client devices 106,108 stored in the memory 556and executable by the processor 553 are a client side application 123 ora key application 163 and potentially other applications. Also stored inthe memory 506 and 556 may be a data store 133 and 113, 115 and otherdata. In addition, an operating system may be stored in the memory 506and 556 and executable by the processor 503 and 553.

It is to be understood that there may be other applications that arestored in the memory 506 and 556 and are executable by the processor 503and 553 as can be appreciated. Where any component discussed herein isimplemented in the form of software, any one of a number of programminglanguages may be employed such as, for example, C, C++, C#, Objective C,Java, Javascript, Perl, PHP, Visual Basic, Python, Ruby, Delphi, Flash,or other programming languages.

A number of software components are stored in the memory 506 and 556 andare executable by the processor 503 and 553. In this respect, the term“executable” means a program file that is in a form that can ultimatelybe run by the processor 503 and 553. Examples of executable programs maybe, for example, a compiled program that can be translated into machinecode in a format that can be loaded into a random access portion of thememory 506 and 556 and run by the processor 503 and 553, source codethat may be expressed in proper format such as object code that iscapable of being loaded into a random access portion of the memory 506and 556 and executed by the processor 503 and 553, or source code thatmay be interpreted by another executable program to generateinstructions in a random access portion of the memory 506 and 556 to beexecuted by the processor 503 and 553, etc. An executable program may bestored in any portion or component of the memory 506 and 556 including,for example, random access memory (RAM), read-only memory (ROM), harddrive, solid-state drive, USB flash drive, memory card, optical discsuch as compact disc (CD) or digital versatile disc (DVD), floppy disk,magnetic tape, or other memory components.

The memory 506 and 556 are defined herein as including both volatile andnonvolatile memory and data storage components. Volatile components arethose that do not retain data values upon loss of power. Nonvolatilecomponents are those that retain data upon a loss of power. Thus, thememory 506 and 556 may comprise, for example, random access memory(RAM), read-only memory (ROM), hard disk drives, solid-state drives, USBflash drives, memory cards accessed via a memory card reader, floppydisks accessed via an associated floppy disk drive, optical discsaccessed via an optical disc drive, magnetic tapes accessed via anappropriate tape drive, and/or other memory components, or a combinationof any two or more of these memory components. In addition, the RAM maycomprise, for example, static random access memory (SRAM), dynamicrandom access memory (DRAM), or magnetic random access memory (MRAM) andother such devices. The ROM may comprise, for example, a programmableread-only memory (PROM), an erasable programmable read-only memory(EPROM), an electrically erasable programmable read-only memory(EEPROM), or other like memory device.

Also, the processor 503 and 553 may represent multiple processors, andthe memory 506 and 556 may represent multiple memories that operate inparallel processing circuits, respectively. In such a case, the localinterface 509 and 559 may be an appropriate network 109 (FIG. 1) thatfacilitates communication between any two of the multiple processors 503and 553, or between any two of the memories 506 and 556, etc. The localinterface 509 and 559 may comprise additional systems designed tocoordinate this communication, including, for example, performing loadbalancing. The processor 503 and 553 may be of electrical or of someother available construction.

Although the authorization service 136, distribution service 137, clientside application 123, key application 163, and other various processesand functionality described herein may be embodied in software or codeexecuted by general purpose hardware as discussed above, as analternative the same may also be embodied in dedicated hardware or acombination of software/general purpose hardware and dedicated hardware.If embodied in dedicated hardware, each can be implemented as a circuitor state machine that employs any one of or a combination of a number oftechnologies. These technologies may include, but are not limited to,discrete logic circuits having logic gates for implementing variouslogic functions upon an application of one or more data signals,application specific integrated circuits having appropriate logic gates,or other components, etc. Such technologies are generally well known bythose skilled in the art and, consequently, are not described in detailherein.

It is to be understood that the flowcharts of FIG. 2, FIG. 3 and FIG. 4provide merely examples of the many different types of functionalarrangements that may be employed to implement the operation of theclient side application 123 and authorization service 136, respectively,as described herein. The flowcharts may also be viewed as depictingexamples of methods implemented in the client device 106 and theenterprise server 103 (or other network device), respectively, accordingto one or more embodiments. If embodied in software, each method step orbox of the flowcharts may represent a module, segment, or portion ofcode that comprises program instructions to implement the specifiedlogical function(s). The program instructions may be embodied in theform of source code that comprises human-readable statements written ina programming language or machine code that comprises numericalinstructions recognizable by a suitable execution system such as aprocessor 503 and 553 in a computer system or other system. The machinecode may be converted from the source code, etc. If embodied inhardware, each block may represent a circuit or a number ofinterconnected circuits to implement the specified logical function(s).

Although the flowcharts of FIG. 2, FIG. 3 and FIG. 4 show a specificorder of execution, it is understood that the order of execution maydiffer from that which is depicted. For example, the order of executionof two or more steps may be scrambled relative to the order shown. Also,two or more blocks shown in succession in FIG. 2, FIG. 3 or FIG. 4 maybe executed concurrently or with partial concurrence. Further, in someembodiments, one or more of the steps shown in FIG. 2, FIG. 3 or FIG. 4may be skipped or omitted. In addition, any number of counters, statevariables, warning semaphores, or messages might be added to the logicalflow described herein, for purposes of enhanced utility, accounting,performance measurement, or providing troubleshooting aids, etc. It isunderstood that all such variations are within the scope of the presentdisclosure.

Also, any logic or application described herein, including theauthorization service 136, distribution service 137, client sideapplication 123, and key application 163, that comprises software orcode can be embodied in any non-transitory computer-readable medium foruse by or in connection with an instruction execution system such as,for example, a processor 503 and 553 in a computer system or othersystem. In this sense, the logic may comprise, for example, statementsincluding instructions and declarations that can be fetched from thecomputer-readable medium and executed by the instruction executionsystem. In the context of the present disclosure, a “computer-readablemedium” can be any medium that can contain, store, or maintain the logicor application described herein for use by or in connection with theinstruction execution system. The computer-readable medium can compriseany one of many physical media such as, for example, magnetic, optical,or semiconductor media. More specific examples of a suitablecomputer-readable medium would include, but are not limited to, magnetictapes, magnetic floppy diskettes, magnetic hard drives, memory cards,solid-state drives, USB flash drives, or optical discs. Also, thecomputer-readable medium may be a random access memory (RAM) including,for example, static random access memory (SRAM) and dynamic randomaccess memory (DRAM), or magnetic random access memory (MRAM). Inaddition, the computer-readable medium may be a read-only memory (ROM),a programmable read-only memory (PROM), an erasable programmableread-only memory (EPROM), an electrically erasable programmableread-only memory (EEPROM), or other type of memory device.

It should be emphasized that the above-described embodiments of thepresent disclosure are merely possible examples of implementations setforth for a clear understanding of the principles of the disclosure.Many variations and modifications may be made to the above-described andother possible embodiment(s) without departing substantially from thespirit and principles of the disclosure. All such modifications andvariations are intended to be included within the scope of thisdisclosure and the following claims.

What is claimed is:
 1. A method, comprising: causing a resource to beencrypted to create an encrypted version of the resource, the encryptedversion of the resource being configured to be inaccessible by a primaryclient device, the encrypted version of the resource being configured tobe decrypted using an authorization credential to create an unencryptedversion of the resource, and the unencrypted version of the resourcebeing configured to be accessible by the primary client device; causingthe encrypted version of the resource to be provided to the primaryclient device; determining that the primary client device is authorizedto access the unencrypted version of the resource based at least in parton a first distribution rule, the first distribution rule beingassociated with the primary client device; determining that a secondaryclient device is authorized to provide the primary client device withthe unencrypted version of the resource based at least in part on asecond distribution rule, the second distribution rule being associatedwith the secondary client device; and, causing the authorizationcredential to be provided to the secondary client device.
 2. The methodof claim 1, further comprising: identifying a request by the primaryclient device to access the resource.
 3. The method of claim 1, furthercomprising: identifying a request by the secondary client device forauthorization to provide the primary client device with the unencryptedversion of the resource.
 4. The method of claim 1, wherein theauthorization credential comprises a decryption key.
 5. The method ofclaim 1, wherein the first distribution rule specifies that the primaryclient device must be physically located within a particular thresholddistance of the secondary client device.
 6. The method of claim 1,wherein the first distribution rule specifies that the primary clientdevice must be communicatively coupled to the secondary client devicethrough a particular network.
 7. A non-transitory computer readablemedium comprising executable instructions, which when executed by atleast one processor, cause a computing device to at least: cause aresource to be encrypted to create an encrypted version of the resource,the encrypted version of the resource being configured to beinaccessible by a primary client device, the encrypted version of theresource being configured to be decrypted using an authorizationcredential to create an unencrypted version of the resource, and theunencrypted version of the resource being configured to be accessible bythe primary client device; cause the encrypted version of the resourceto be provided to the primary client device; determine that the primaryclient device is authorized to access the unencrypted version of theresource based at least in part on a first distribution rule, the firstdistribution rule being associated with the primary client device;determine that a secondary client device is authorized to provide theprimary client device with the unencrypted version of the resource basedat least in part on a second distribution rule, the second distributionrule being associated with the secondary client device; and, cause theauthorization credential to be provided to the secondary client device.8. The non-transitory computer readable medium of claim 7, furtherincluding executable instructions, which when executed by the at leastone processor, cause the computing device to: identify a request by theprimary client device to access the resource.
 9. The non-transitorycomputer readable medium of claim 7, further including executableinstructions, which when executed by the at least one processor, causethe computing device to: identify a request by the secondary clientdevice for authorization to provide the primary client device with theunencrypted version of the resource.
 10. The non-transitory computerreadable medium of claim 7, wherein the first distribution rulespecifies that the primary client device must comprise at least one of:a particular hardware component, a particular software component, or aparticular device configuration.
 11. The non-transitory computerreadable medium of claim 10, further including executable instructions,which when executed by the at least one processor, cause the computingdevice to: identify information describing at least one aspect of theprimary client device, the at least one aspect comprising at least oneof: a hardware component of the primary client device, a softwarecomponent of the primary client device, or a particular deviceconfiguration of the primary client device.
 12. The non-transitorycomputer readable medium of claim 7, wherein the second distributionrule specifies that the secondary client device must comprise at leastone of: a particular hardware component, a particular softwarecomponent, or a particular device configuration.
 13. The non-transitorycomputer readable medium of claim 12, further including executableinstructions, which when executed by the at least one processor, causethe computing device to: identify information describing at least oneaspect of the secondary client device, the at least one aspectcomprising at least one of: a hardware component of the secondary clientdevice, a software component of the secondary client device, or aparticular device configuration of the secondary client device.
 14. Acomputing device, including: at least one processor; and, at least onememory comprising executable instructions, which when executed by the atleast one processor, cause the computing device to at least: cause aresource to be encrypted to create an encrypted version of the resource,the encrypted version of the resource being configured to beinaccessible by a primary client device, the encrypted version of theresource being configured to be decrypted using an authorizationcredential to create an unencrypted version of the resource, and theunencrypted version of the resource being configured to be accessible bythe primary client device; cause the encrypted version of the resourceto be provided to the primary client device; determine that the primaryclient device is authorized to access the unencrypted version of theresource based at least in part on a first distribution rule, the firstdistribution rule being associated with the primary client device;determine that a secondary client device is authorized to provide theprimary client device with the unencrypted version of the resource basedat least in part on a second distribution rule, the second distributionrule being associated with the secondary client device; and, cause theauthorization credential to be provided to the secondary client device.15. The computing device of claim 14, further including executableinstructions, which when executed by the at least one processor, causethe computing device to: identify a request for the primary clientdevice to access the resource.
 16. The computing device of claim 14,further including executable instructions, which when executed by the atleast one processor, cause the computing device to: identify a requestby the secondary client device for authorization to provide the primaryclient device with the unencrypted version of the resource.
 17. Thecomputing device of claim 14, wherein the first distribution rulespecifies that the primary client device must be operated by anauthorized user based at least in part on a user credential provided bya user of the primary client device.
 18. The computing device of claim17, wherein the user credential comprises at least one of: a personalidentification number (PIN), a password, a certificate, or a token. 19.The computing device of claim 14, wherein the second distribution rulespecifies that the secondary client device must be operated by anauthorized user based at least in part on a user credential provided tothe secondary client device.
 20. The computing device of claim 19,wherein the user credential comprises at least one of: a personalidentification number (PIN), a password, a certificate, or a token.